REMARKS 

Claims 1-4, 6-10, and 12-27 are pending in this application. In this Response, Applicant 
has amended certain claims. Claims 1,16 and 22 have been amended. The Applicant respectfully 
provides the following remarks for consideration. 

A. Rejection under 35 U.S.C § 101 

The Examiner rejected claims 1-4, 6-10, and 12-27 because the claimed subject matter is 
directed to non-statutory subject matter. 

The Applicant respectfully traverses this rejection for claims 1-4, 6-10 and 12-15. These 
claims are directed to a system that produces tangible results. Accordingly, the Applicant 
respectfully requests that the rejection is withdrawn. 

Claims 16-27 have been amended to recite that the method is a computer implemented 
method. Accordingly, the rejection is believed to be overcome and withdrawal of the rejection is 
respectfully requested. 

B. Rejection under 35 U.S.C. § 112 

The Examiner rejected claimsl-4, 6-10 and 12-15 under 35 U.S.C. § 112, second 
paragraph, as being indefinite for failing to particularly point and distintly claim the subject matter 
which applicant regards as the invention. 

The Applicant has amended claim 1 to provide antecedent basis for the limitation "database" 
and has removed recitation of the limitation "determined/ The rejection is believed to be overcome 
and withdrawal of the rejection is respectfully requested. 

B. Rejection under 35 U.S.C. § 103 

In the Office Action, claims 1, 3, 6-8, 12 and 14 were rejected under 35 U.S.C. §102(b) as 
being obvious in view of U.S. Patent Publication 2002/0198798 by Ludwig et al. ("Ludwig"). 
Applicant submits that Ludwig does not disclose the present invention for the reasons that 
follow. 
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The present invention and Ludwig el al's modular business transactions platform are two 
totally different systems. The present invention is a web-based content, mostly document, 
management and distribution system, whereas Ludwig et al's business transactions platform 
describes a web-based payment and billing system. The present invention deals with mostly 
electronic documents/reports, whereas Ludwig et aPs invention invoices. Invoices need to comply 
with certain standards ANSI XI 2 8 10 or in a plain text such as flat ASCII files or well formed 
XML schemas to allow exchange data or transaction between a biller's system and payer's 
system. The present invention is not a transaction or payment system. In general, The present 
invention is a specially designed Electronic Document Management System that is typically used 
to manage files that are created by other application, such as Word Application. These documents 
are not restricted to transcribed ones. These documents can be very complicated and do not need 
to follow any standards like invoices. At present, The present invention is used now to store, 
manage and distribute Radiology and their meta-information. 

Ludwig does not disclose a central file system for storing a plurality of documents, each of 
said plurality of documents being stored said central file system based on at least in part on a 
respective status of said plurality of documents. In the present invention design, a central file 
system refers to a logically central storage area that is accessible by the application of the present 
invention. The central file system is divided into different portions and each portion of the central 
file system stores an electronic document based on its processing status. For instance, an 
electronic document that is being edited or reviewed is stored in an Edit folder or an image 
column in the Edit table in a SQL database server. An electronic document that is being reviewed 
or approved is stored in an Approved folder or an image column in the Approved table in a SQL 
database server. An electronic document that has gone through all process phases is stored in a 
Report folder or an image column in the Report table in a SQL database server. Further, a 
processed electronic document can be stored in either an active Report folder table or an inactive 
Report depending on how often the user needs to access to it. 

In contrast, Ludwig' s invoices are not stored in a folder in a file system, but instead 
invoices are broken down into elements and stored in a database. Ludwig et describes only how 
to select invoice and change the display of invoice in paragraph 008 1 ;and how to change the 
status of an invoice from Open to Closed and a Closed invoice may not be accessible, subject to 
archiving or purging in paragraph 0082; how to mark an invoice paid through another source and 
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how to display invoices in paragraphs 0083; and how to perform adjustment for a biller's system 
and make the adjustment available to the system in 0097 paragraph. These paragraphs did not 
state or imply where and how an invoice is stored at all Furthermore, an electronic document 
such as a radiology report needs to be processed in a way distinctively different from an invoice. 
Thus, where and how an electronic document is stored according to its process status and its 
possibility of the future use should be very different from an invoice. 

Ludwig does not disclose a content indexing module operable to create an index of said 
plurality of documents in said central file system, wherein an index for document in the index of 
the plurality of document is at least a value associated with a predefined ascii pattern in the 
content of the document. The invoice of Ludwig has limited items, and is defined in a certain 
format and order. Therefore, the translation from a biller's accounting system format to a payer's 
accounting system format, as mentioned in Ludwig, only involves item position mapping between 
two formats, based on the order in which the items occur. 

In contrast, the electronic documents of the present invention are more complicated, and 
the contents in different documents may occur in an order or not in any order, therefore all criteria 
that can help uniquely identify the contents, such as the string match, string position, string repeat 
pattern, document format, and like comma, period, end of line, paragraph mark et al, are all used 
to find the contents in the present invention. Ludwig et did not state what criteria they use to 
translate an invoice from a payer's accounting format to a biller's accounting format, and did not 
imply that the method of an invoice format translation can be applied to locating a needed content 
in any electronic document. 

Ludwig does not disclose a document distribution module operable to distribute at least 
one of said plurality of documents to at least one of a plurality of determined recipients based at 
least in part on a preference of said at least one of said plurality of recipients stored in said 
database. Ludwig's invention deals with only two directly interacting entities, payer and biller. A 
payer has to register himself to the system in order to use the system. Therefore, notices of 
invoices may be automatically sent out to one or more payers, based on the correct and complete 
information provided by one to one match between an invoice and a payer is only an ideal and 
rare case for the present invention system. The present invention system has to provide several 
recipients address pairs for the people who handle report delivery, based on the best-match 
through searching the database. Thus, the present invention system provides not only an 
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automatic report delivery function like Ludwig et invention but also a semi-automatic report 
delivery function in the case a recipient data is not complete on the radiology report. Since The 
present invention system needs to deal with multiple entities, referring physicians, patients, 
insurer, radiologist association, radiologists, and transcriptists. 

Ludwig does not suggest storing a plurality of documents in only one of the at least two 
folders or storing documents in folders. Electronic documents can be related by various ways, by 
their categories, creation time and contents. The present invention stores electronic documents in 
different folders in a file system or different tables in a database based on their processing status. 
As the types of electronic documents increases, The present invention separates electronic 
documents by their processing status as well as their categories. Thus, a general deduction may 
not be appropriate. 

Claims 3, 6-8, 12 and 14 depend from claim 1, and thus, are not taught for the same reasons 
discussed above with respect to claim 1 . 

The examiner rejected claims 9-10 under 35 U.S.C. 103(a) as being unpatentable over 
Ludwig et al. (U.S. Pub. 2002101 98798 Al) in view of Podhradsky (U.S. Patent No. 5,978,755 
("Podhradsky"). 

Claims 9 and 10 depend from claim 1. As discussed above Ludwig does not teach the 
invention of claim 1. Podhradsky does not cure the deficiencies of Ludwig nor does it teach claim 
9. Podhradsky states at columns 14, line 61-67 that the additional designation record which 
provides information about the number of words in a dictation, can be used, for example when a 
dictation is transcribed or when a dictation has been completed, to bill for example the author of 
the dictation, the amount of the bill being based on the number of transcribed words, the number 
of words comprised in a dictation. Podhradsky' s invention gets the number of words by the 
additional designation record in a dictation device from digitized speech signals, and thus, his 
invention can only be applied in transcribing dictation. The present invention gets the number of 
words by reading through strings in a document, counts letters, words or lines from any electronic 
document, not restricted to the one transcribed from a digitized dictation. Accordingly, the 
combination Ludwig and Podhradsky does not teach the invention of claim 9. 

The modified invention of Ludwig et al. fails to teach claim 10. Ludwig et al's invention 
starts with loading invoices into the system, and not generating. See Ludwig, figures 1 and 4). 
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Ludwig did not discuss or imply their system will generate invoices and charge users based on the 
number of invoices or in invoices the system processed at all. Therefore, it would not have been 
obvious to having ordinary skill in the art at the time the invention was made to provide for 
wherein said invoice is generated based at least in part on the number of lines in said at least one 
of said plurality of documents since it was known in the art that that charging for a unit of 
transcription of a document including words and lines of a text would enable a calculation based 
on the amount of text that has to be translated, the combination Ludwig and Podhradsky does not 
teach the invention of claim 10. 

The Examiner rejected claims 2, 4, 15-22, and 26-27 are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Ludwig et al. (U.S. Pub. No. 200210198798 Al) in view of Lucas et al. 
(U.S. Pub. No. 200210143533 Al). 

Claims 2, 4 and 15 depend from claim 1. As discussed above Ludwig does not teach the 
invention of claim 1. Lucas does not cure the deficiencies of Ludwig. Accordingly, the 
combination of Ludwig and Lucas does not teach the invention of claims 2, 4 and 15. 

Moreover, Lucas does not teach wherein each of a selected plurality of said plurality of 
documents comprises a transcribed document as claimed in claim 2. The documents referred by 
Lucas are predefined document/form templates, not transcribed documents. See Lucas et al. page 
1, paragraph 0006, also see Lucas et al. page 1, paragraph 0017. In Lucas et aPs invention, a 
dictated speech is transcribed and then filled sequentially in the predefined fields in a selected 
document/form template to generate a complete document. Their templates may be organized but 
may not need to be routed. In their invention, they did not discuss the completed and transcribed 
documents or forms need to be routed as their statuses change from review, to approval, and 
distribution, and from active to inactive. 

Claim 16 recites limitation similar to claim 1 . As discussed above Ludwig does not teach 
storing a plurality of documents in a folder of a plurality of folders of a central file system. In 
addition, Ludwig discloses only how to allow a user to select invoices and display selected 
invoices for a user in paragraph 008 1; how to close selected invoices in paragraph 0082; and how 
to close an invoice that is paid through another source in 0083; and how to make adjustment for 
general, quantity, price, line item allowance, etc in paragraph 0097. 

Ludwig also fails to teach creating a plurality of indexes indexing said plurality of 
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documents, wherein each index in said plurality of indexes is at least a value associated with a 
predefined ascii pattern comprising at least one indexing field in the contents of the document. 
Ludwig discloses only converting invoice files from the biller's accounting system to the invoice 
loader format in paragraph 0036; allowing users manually to load selected invoice files or to 
control the automatic loading times of biller uploads in paragraph 0066; providing users display 
view options and search function in paragraph 0087; retrieving closed invoices and changing 
closed invoices to the open state in paragraph 0087; and allowing users to modify or select export 
templates or export files to export invoices data through populating the fields of the selected 
template setting areas by the system in paragraph 0088. As discussed above, an invoice has 
limited items, and is defined in a certain format and order. Therefore, the translation from a 
biller's accounting system format to a payer's accounting system format may only involve item 
position mapping between two formats, based on the order in which the items occur. In contrast, 
an electronic document can be more complicated, and the contents in different documents may 
occur in an order or not in any order, therefore all criteria that can help uniquely identify the 
contents, such as the string match, string position, string repeat pattern, document format, and like 
comma, period, end of line, paragraph mark et al, are all used to find the contents in the present 
invention. Ludwig et did not described what criteria they use to translate an invoice from a 
biller's accounting format to a payer's accounting format, and did not imply that the method of an 
invoice format translation can be applied to locating a needed content in any electronic document. 

Ludwig also fail to disclose automatically recommending to a user a preferred method of 
distributing a document of said plurality of documents to a recipient based at least in part on a 
preference of said recipient. Ludwig discloses sending email-notice of a new invoice to a payer in 
paragraph 0038; making adjustment to invoices and sending invoices with notes in email; and 
setting or modifying payer's options, closing invoices and emailing in paragraph 0096. Ludwig 
only discloses one method of distributing an invoice or message. Accordingly, there is no need 
for a preferred method of distributing an electronic document. The present invention provides 
email, fax, web-site/ftp download and even hard copy mailing choices for users. Thus, users can 
select the preferred methods of distributing electronic documents for their recipients, and the 
present invention keeps the information for users. 

Lucas does not cure the deficiencies of Ludwig. As discussed above, the document of 
Lucas referred to in paragraphs 0006 and 00 17 is a template or "a type of document or form that 
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the user wishes to populate, or fill-in, with text." Accordingly, the combination of Ludwig and 
Lucas does not teach the invention of claim 16. 

Claims 17-22, 26 and 27 depend from claim 16 and is not taught for at least the same 
reasons discussed above with respect to claim 16. 

The Examiner rejected claims 23-25 under 35 U.S.C. 103(a) as being unpatentable over 
Ludwig et al. (U.S. Pub. No. 200210198798 Al) in view of Lucas et al. (U.S. Pub. No, 
200210143533 Al), and further in view of Podhradsky (U.S. Patent No. 5978755 ("Podhradsky"). 

Claims 23-25 depend from claim 16. As discussed above, the combination of Ludwig and 
Lucas does not teach the invention of claim 16. Podhradsky does not cure the deficiencies of 
Ludwig and Lucas. Accordingly, the combination of Ludwig, Lucas and Podhradsky does not 
teach the invention of claims 23-25. 



All claims are believed to be in condition for allowance. If the Examiner believes that 
the present amendments still do not resolve all of the issues regarding patentability of the 
pending claims, Applicant invites the Examiner to contact the undersigned attorneys to discuss 
any remaining issues. A Petition for a two month Extension of Time is submitted herewith. No 
other fees are believed to be due at this time. Should any fee be required, however, please 
charge such fee to Bingham McCutchen, LLP Deposit Account No. 195127, Order No. 
25241.0004. 



CONCLUSION 



Respectfully submitted, 
Bingham McCutchen, LLP 



Dated: 



March 23, 2006 




Washington, D.C. 20007^. 
(202) 373-6661 Telephone 
(202) 295-8478 Facsimile 
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